Method and system for the dynamic scheduling of requests to access a storage system

ABSTRACT

A method and system in data processing system are disclosed for the dynamic scheduling of a plurality of requests to access a disk. Each of the requests is associated with a location on the said disk which each of the requests is attempting to access. A scan queue is established for storing the plurality of requests. The plurality of requests are processed in a sequential order. The sequential order is determined utilizing the location on the disk being accessed by each of the requests. Upon one of the stored requests being urgent, the urgent request is processed. The urgent request is associated with a first location on said disk. Processing of the requests then continues in a second sequential order. The second sequential order is determined utilizing the first location. The next request to be processed is one of the requests which is associated with a physically closest location on the disk.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates to data processing systems, and inparticular to a method and system in a data processing system fordynamically scheduling a plurality of requests which include real-timeand non-real-time requests. Still more particularly, the presentinvention relates to a method and system in a data processing system forscheduling non-real-time requests for processing as long as none of thereal-time requests are urgent.

2. Description of the Related Art

Devices in a data processing system, such as disk drive adapters, areusually connected via a bus to transmit data from one device to and fromother system resources, such as the central processor and memory. Eachof these devices has data that it normally transfers. For example, onedevice may normally transfer real-time data such as is necessary todisplay a multimedia presentation. A second device may normally transfernon-real-time data that may be a file transfer. A third device maytransfer both real-time and non-real-time data. The data transferred bythese devices may be stored in a disk drive.

Real-time data is data that has an associated deadline. The deadlinedefines the time by which the real-time data must be transferred.Failure to transfer real-time data prior to the associated deadline willresult in lost data. Non-real-time data has no associated deadline.

A computer system needs to support the transfer of both real-time andnon-real-time data simultaneously. Often, however, when both real-timeand non-real-time data are supported simultaneously, real-time data isnot transferred in a timely manner without adversely affectingnon-real-time data transfer. Since many of the data transfers come fromdisks, effective, efficient disk scheduling is important to providetimely delivery of data.

Modern disk storage systems use scheduling algorithms to order requeststo minimize the amount of seeking, i.e. physical arm movement, a diskmust do in order to locate the requested data. One such algorithm iscalled the elevator or SCAN algorithm. Each data request has anassociated track on the physical disk on which the requested data isstored. This algorithm orders requests according to the track locationon the disk where the data is stored. The disk first services therequest for data stored on the outermost track, and then proceeds toservice requests for data stored on tracks that are ordered towards theinnermost track. Therefore, the disk is initially traversed fromoutermost to innermost track. When the innermost track that containsrequested data is reached, the direction is reversed so that the disk istraversed from innermost track to outermost track, like an elevatorstopping at selected floors. A variant of SCAN is called CSCAN. InCSCAN, instead of reversing direction when the innermost track isreached, the arm will travel back to the outermost track and seek inwardagain.

Therefore a need exists for a method and system in a data processingsystem to dynamically schedule a plurality of requests that includereal-time and non-real-time requests, where the non-real-time requestsare scheduled until a real-time request becomes urgent.

SUMMARY OF THE INVENTION

One object of the present invention is to provide an improved dataprocessing system.

Another object of the present invention is to provide a method andsystem in a data processing system for dynamically scheduling aplurality of requests that include both real-time and non-real-timerequests.

It is yet another object of the present invention to provide a methodand system in a data processing system for dynamically scheduling aplurality of requests for processing as long as none of the real-timerequests are urgent.

The foregoing objectives are achieved as is now described. A method andsystem in data processing system are disclosed for the dynamicscheduling of a plurality of requests to access a disk. Each of therequests is associated with a location on the said disk which each ofthe requests is attempting to access. A scan queue is established forstoring the plurality of requests. The plurality of requests areprocessed in a sequential order. The sequential order is determinedutilizing the location on the disk being accessed by each of therequests. Upon one of the stored requests being urgent, the urgentrequest is processed. The urgent request is associated with a firstlocation on said disk. Processing of the requests then continues in asecond sequential order. The second sequential order is determinedutilizing the first location. The next request to be processed is one ofthe requests which is associated with a physically closest location onthe disk.

The above as well as additional objectives, features, and advantages ofthe illustrative embodiment will become apparent in the followingdetailed written description.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features are set forth in the appended claims. The presentinvention itself, however, as well as a preferred mode of use, furtherobjectives and advantages thereof, will best be understood by referenceto the following detailed description of a preferred embodiment whenread in conjunction with the accompanying drawings, wherein:

FIG. 1 depicts a high level block diagram of a data processing systemwhich may be utilized to implement the method and system of the presentinvention;

FIG. 2 illustrates a pictorial representation of scan queue elements andthe associated fields included within each element in accordance withthe method and system of the present invention;

FIG. 3 illustrates a high level flow chart which depicts the creation ofa scan queue element and the insertion of the element into the scanqueue in accordance with the method and system of the present invention;

FIGS. 4-6 together depicts a high level flow chart which illustrates theremoval of scan queue elements from the scan queue in accordance withthe method and system of the present invention;

FIG. 7 depicts a plurality of scan queue elements stored within a scanqueue, a most urgent soft real-time buffer, a most urgent hard real-timebuffer, a current time clock, and a current track scan pointer inaccordance with the method and system of the present invention;

FIG. 8 illustrates the scan queue elements stored within a scan queue,the most urgent soft real-time buffer, the most urgent hard real-timebuffer, the current time clock, and the current track scan pointer ofFIG. 7 after the next sequential request has been removed in accordancewith the method and system of the present invention; and

FIG. 9 depicts the scan queue elements stored within a scan queue, themost urgent soft real-time buffer, the most urgent hard real-timebuffer, the current time clock, and the current track scan pointer ofFIG. 8 after two more elements have been removed and a non-real-timeelement has been added in accordance with the method and system of thepresent invention.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

A preferred embodiment of the present invention and its advantages arebetter understood by referring to FIGS. 1-9 of the drawings, likenumerals being used for like and corresponding parts of the accompanyingdrawings.

The present invention defines two categories of real-time requests: hardreal-time requests and soft real-time requests. These requests, alongwith non-real-time requests are stored in a scan queue and processedsequentially inaccordance with a SCAN or CSCAN algorithm until one ofthe real-time requests becomes urgent. The urgent request is thenprocessed. The remaining requests are then processed sequentially fromthe location of the urgent real-time request.

All hard real-time requests are processed, even if they are past theirassociated deadlines. Soft real-time requests past their associateddeadlines are discarded.

Real-time data may be classified into two categories: “hard real-timedata” and “soft real-time data”. Hard real-time data is data that mustbe transferred within a specified period of time. Failure to transferany portion of hard real-time data before the deadline is catastrophicbecause critical data will be lost. Thus, the performance objective forthe transfer of hard real-time data is to have no missed deadlines, andconsequently, no lost data. An example of hard real-time data isaircraft flight system data.

Soft real-time data is data that should be transferred within aspecified period of time, or deadline. Failure to transfer softreal-time data before the deadline results in lost data, where loss ofsome data is tolerable. The performance objective for the transfer ofsoft real-time data is to have a low percentage of missed deadlines, andconsequently, a low percentage of lost data. An example of softreal-time data is packetized voice data.

FIG. 1 depicts a pictorial representation of a data processing system 10which may be utilized to implement the method and system of the presentinvention. Data processing system 10 includes a disk 16 and aprinter/output device 18. One or more disks may be utilized to store thevarious data objects or files which may be periodically accessed,processed, and presented within data processing system 10 in accordancewith the method and system of the present invention.

Data processing system 10 may be implemented utilizing any suitablyconfigured personal computer, mini computer, or mainframe computer. Dataprocessing system 10 includes a CPU 17, memory 21, a computer display19, keyboard 20, input pointing device 22, and speakers 24. Thoseskilled in the art will appreciate that input pointing device 22 may beimplemented utilizing a pointing stick, a mouse, a track ball, or a pen.

The process described herein are supported by mechanisms within a diskadapter 28. Disk adapter 28 is coupled to CPU 17 by means of an I/O bus26. In current systems, this bus is typically a PCI bus. Adapter 28includes an I/O bus interface unit (BIU) 40. The I/O BIU 40 manages theprotocol necessary for data and control information to be transmittedacross I/O bus 26 between adapter 40 and CPU 17 and memory 21 to whichadapter 28 is attached. In a similar fashion, disk adapter 28 attachesto disk 16 by means of a disk bus 34. In current systems bus 34 istypically a SCSI bus. Similarly, adapter 28 includes a disk BIU 42. DiskBIU 42 manages the protocol necessary for data and control informationto be transmitted across disk bus 34 between adapter 28 and disk 16.Within adapter 28 there is a processing unit 44. Processing unit 44 canbe implemented as a state machine or as a programmable microprocessor.Processing unit 44 is capable of executing the algorithms specifiedherein, as well as accessing the data stored in adapter memory 46.

Within adapter 28 is adapter memory 46. Adapter memory 46 can beimplemented using Random Access Memory (RAM). Adapter processor 44 iscapable of addressing locations within RAM 46, and can read and writedata to adapter memory 46. Data and control information to or from theCPU 17 can be stored in adapter memory 46. Also contained within adaptermemory 46 are a number of software data structures which are describedbelow.

When adapter 28 is initially powered on, adapter 28 will perform anumber of specific operations which include establishing a buffer poolspace in adapter memory 46, establishing the scan queue data structurewithin adapter memory 46, and determining the geometry of the attacheddisk 16.

While data processing system 10 is in operation, adapter 28 will collectinformation that can be used in an effort to control the performance ofadapter 28. This information is collected and stored in adapter memory46. The information includes the number of times a hard real-timedeadline was missed, the number of times soft real-time data werediscarded due to a missed deadline, and the number of requests that havebeen serviced.

When adapter 28 is in operation, the information collected will beperiodically checked by CPU 17. Depending on the values collected, CPU17 will control the flow of data through adapter 28.

Adapter memory 46 represents a collection of addressable storagelocations within adapter 28. Adapter memory 46 is separate from andindependent of memory 21.

A number of logical data structures are contained within memory 46 ofadapter 28:

(1) A scan queue 50: A specialized version of a doubly linked list datastructure, for the purpose of ordering the outstanding requests to thedisk. Scan queue 50 includes a plurality of scan elements 52.

(2) A buffer pool: A pool of storage locations where the I/O controlblocks received from CPU 17 are stored.

(3) A set of four buffers:

(A) Most urgent hard real-time request buffer 54: This buffer includestwo fields. The first field 56 includes the time, also called adeadline, by which the most urgent hard real-time request must beserviced. The second field 58 includes a pointer to the location in scanqueue 50 that contains the most urgent hard real-time request. Whenthere are no hard real-time requests in scan queue 50, the value infield 58 is set to the NULL value.

(B) Most urgent soft real-time request buffer 60: This buffer includestwo field. The first field 62 includes the time, i.e. deadline, by whichthe most urgent soft real-time request must be serviced. The secondfield 64 includes a pointer to the location in scan queue 50 thatincludes the most urgent soft real-time request. In the event there areno soft real-time requests in scan queue 50, the value in field 64 isset to the NULL value.

(C) Current scan track pointer 66: The scan track pointer bufferincludes two fields. The first field 68 includes a pointer to theelement in scan queue 50 that is to be served next by disk 16. Thesecond field 70 includes an indicator as to the direction in scan queue50 to select the next element. This indicator can specify eitherascending or descending track numbers.

(D) Status register which also includes the current time clock count 72:The status register includes three fields which are pertinent to theoperation of the present invention. The first field includes a disk busyindicator. This indicator is set when the disk is busy serving a requestand no further requests can be dispatched to it. This indicator is resetwhen the disk can receive another request. The second field contains thescan queue empty indicator. This indicator is set when there are one ormore elements in the scan queue. It is reset when there are no elementsin the scan queue. The third field 72 includes the current clock value.This is an encoding of the current time. The encoding is consistent withthe time encoding included within the requests.

Scan queue 50 is a doubly linked list. The request which is to beserviced next by disk 16 is selected by traversing scan queue 50. Also,when either the most urgent hard real-time request or the most urgentsoft real-time request must be immediately serviced, the current pointercan be directly updated and the scan can effectively continue withoutthe need for reordering scan queue 50.

Scan queue elements 52 have the structure as depicted in FIG. 2. In amanner consistent with the concept of a doubly linked list, the scanqueue ascending pointer 80 points to the element of scan queue 50 whichwould have the next higher track number. Similarly, the scan queuedescending pointer 82 points to the element of scan queue 50 which wouldhave the next lower track number. When the value in scan queue ascendingpointer 80 is set to NULL, this indicates that this element is the lastelement in scan queue 50, i.e. the element with the highest tracknumber. Similarly, when the value in scan queue descending pointer 82 isset to NULL, this indicates that this element is the first element inscan queue 50, i.e. the element with the lowest track number. When scanqueue ascending pointer 80 and scan queue descending pointer 82 of aelement are both NULL, the element is the only element in scan queue 50.

The request type 84 indicates the type of service request. The requesttypes are hard real-time, soft real-time, and non-real-time.

The track number 86 includes the track number on disk 16 that containsthe requested data. The track number is used to determine where in scanqueue 50 the request is to be placed.

The deadline 88 is used to indicate when the element in scan queue 50must be serviced. The deadline only has relevance if the request isreal-time.

The real-time ascending pointer 90 and the real-time descending pointer92 are used to effectively “chain together” the real-time requests. Justas scan queue 50 is a doubly linked list which indicates the order bywhich requests are to be serviced by disk 16, real-time ascendingpointer 90 and real-time descending pointer 92 are used to order thereal-time requests within scan queue 50 by their urgency. For hardreal-time elements in scan queue 50, their ascending real-time pointer90 points to the next less urgent hard real-time request in scan queue50. Descending real-time pointer 92 points to the next most urgent hardreal-time request in scan queue 50.

Similarly, for soft real-time elements, ascending real-time pointer 90points to the next less urgent soft real-time request in scan queue 50and descending real-time pointer 92 points to the next most urgent softreal-time request in scan queue 50. In both cases, for the most urgentreal-time requests in scan queue 50, setting ascending pointer 90 of ahard real-time element to NULL indicates that this element is the leasturgent hard real-time request currently in scan queue 50. Similarly,setting descending pointer 92 of a hard real-time element is set to NULLindicates that this element is currently the most urgent hard real-timeelement currently in scan queue 50. This principle is the same for thesoft real-time requests currently in scan queue 50. For non-real-timerequests, real-time ascending 90 and descending 92 pointers are set toNULL.

The pointer to buffer pool 94 points to the location in the buffer poolwhere host computer I/O command block data is placed.

The manner by which requests are placed into scan queue 50 is nowdescribed. When an application program running on CPU 17 and accessingmemory 21 wishes to access disk 16, whether to write data to or readdata from disk 16, the application will construct an I/O command requestblock. The I/0 command request block will include specifications for thefollowing data which are significant to the operation of the presentinvention: type of request, deadline, and logical block address. Thedeadline is an encoding of the time by which the request must beserviced. The logical block address is translated by adapter 28 toindicate the disk track number which is used by the present invention.

The I/O command request block will be placed into adapter memory 46where it will be processed. From the information included within therequest block, one or more scan queue elements will be constructed. TheI/O command request block data will be store in the adapter buffer pool.The location in the buffer pool where it is stored is in pointer tobuffer pool 94 in the scan queue element.

FIG. 3 illustrates a high level flow chart which depicts the creation ofa scan queue element and the insertion of the element into the scanqueue in accordance with the method and system of the present invention.The process starts as depicted at block 100 and thereafter passes toblock 102 which illustrates a determination of whether or not the diskis idle and the scan queue is empty. If the disk is idle and the scanqueue is empty, the process passes to block 104 which illustrates therequest that is represented by this element being forwarded directly tothe disk. Otherwise, using the disk track value of the request, adapter28 will traverse the scan queue to determine where in the scan queuethis request is to be placed. The process passes to block 106 whichdepicts adapter 28 checking the type of request received.

The process then passes to block 108 which illustrates a determinationof whether this request is real-time or non-real-time. If the request isa hard real-time or soft real-time request, the process passes to block110 which illustrates adapter 28 checking the deadline for the requestand comparing it to the value in the appropriate most urgent real-timebuffer. Next, block 112 depicts a determination of whether or not thisrequest is more urgent than the most urgent request already stored inscan queue 50. If a determination is made that this request is moreurgent, the process passes to block 114 which illustrates the updatingof the most urgent real-time request time and pointer in the appropriatemost urgent request buffer. The process then passes to block 118.

Referring again to block 112, if a determination is made that thisrequest is not more urgent than the appropriate most urgent requestalready stored, the process passes to block 116 which depicts leavingthe appropriate most urgent real-time buffer alone.

Block 118 illustrates the real-time ascending and real-time descendingpointers being set using the deadline of this new element. The adaptertraverses the list of real-time requests using the real-time ascendingand descending pointers and request type and determines the appropriatesettings for these pointers in a manner consistent with the insertion ofa new element into a doubly linked list. The adapter will then set thepointers in the new scan queue element. Next, block 120 illustratesadapter 28 constructing the new scan queue element and inserting it intothe scan queue. The process then terminates as depicted by block 122.

The assumption has been made that when adapter 28 accepts a request fromCPU 17 there is sufficient space within adapter memory 46 to support theoperation. This includes space within adapter memory 46 to contain ascan queue element. If such space does not exist, adapter 28 will notaccept the request for service.

FIGS. 4-6 together depict a high level flow chart which illustrates theremoval of requests from scan queue 50 in accordance with the method andsystem of the present invention. The process starts as depicted by block200 and thereafter passes to block 202 which illustrates a determinationof whether or not the scan queue is empty. If a determination is madethat the scan queue is empty, the process terminates as depicted byblock 201. If a determination is made that the scan queue is not empty,the process passes to block 204 which illustrates the checking of thecurrent time. Next, block 206 depicts a determination of whether or notthere are any outstanding hard real-time requests in the scan queue. Ifa determination is made that there are no hard real-time requests in thescan queue, the process passes to block 208 which illustrates adetermination of whether or not there are any outstanding soft real-timerequests in the scan queue. If a determination is made that there are nosoft real-time requests in the scan queue, the process passes to block210.

Block 210 depicts the selection of the next request in the scan queuewhich is the next in sequence when utilizing a SCAN or CSCAN algorithm.Thereafter, block 212 depicts a determination of whether or not thisrequest is either the most urgent real-time request or the most urgentsoft real-time request. If a determination is made that this request isnot the most urgent real-time request, the process passes to block 214which illustrates a determination of whether or not the scan directionindicator is set to ascending and the current ascending pointer has avalue of NULL. If a determination is made that the scan directionindicator is not set to ascending or the current ascending pointer doesnot have a value of NULL, the process passes to block 216 which depictsa determination of whether or not the scan direction indicator is set todescending and the current descending pointer has a value of NULL. If adetermination is made that the scan direction indicator is not set todescending or the current descending pointer does not have a value ofNULL, the process passes to block 218 which illustrates the updating ofthe appropriate pointers, removal of the element from the scan queue andthe setting of the disk indicator to busy. The process passes to block219 which depicts the issuing of the request to the disk. The processthen terminates as illustrated by block 220.

Referring again to block 212, if a determination is made that thisrequest is the most urgent real-time request, the process passes toblock 222 which illustrates the updating of the appropriate buffers andthe updating of the scan queue. The process then passes to block 214.

Referring again to block 214, if a determination is made that the scandirection indicator is set to ascending and the current ascendingpointer does have a value of NULL, the process passes to block 224 whichdepicts the changing of the direction indicator to descending and theselection of the next element using the descending pointer. The processthen passes to block 216.

Referring again to block 216, if a determination is made that the scandirection indicator is set to descending or the current descendingpointer does not have a value of NULL, the process passes to block 226which depicts the changing of the direction indicator to ascending andthe selection of the next element using the ascending pointer. Theprocess then passes to block 218.

Referring again to block 206, if a determination is made that there areoutstanding hard real-time requests to be processed, the process passesto block 228 which illustrates a determination of whether or not themost urgent hard real-time request is at or past its deadline. If adetermination is made that no hard real-time request is at or past itsdeadline, the process passes back to block 208.

Referring again to block 228, if a determination is made that there is ahard real-time request at or past its deadline, the process passes toblock 230 which depicts using the pointer included in the most urgenthard real-time buffer to go to that element. Next, block 232 illustratesthe removal of the element from the scan queue. Block 234, then, depictsthe updating of the scan pointer to this element. Since the scan queueis a doubly linked list data structure, the scan queue ascending pointer80 of the element with the next lower track number and the scan queuedescending pointer 82 of the element with the next higher track numberwill be updated in a manner consistent with the removal of an elementfrom a doubly linked list. The process then passes to block 236 whichillustrates using the real-time pointers in this scan queue element tofind the next most urgent real-time request, and the updating of themost urgent hard real-time buffer. Thereafter, block 238 depicts thesetting of the disk indicator to busy. The process then passes back toblock 219.

Referring again to block 240, if a determination is made that the mosturgent soft real-time request is at or past its deadline, the processpasses to block 242 which illustrates a determination of whether or notthe deadline has passed. If a determination is made that the deadlinehas passed, the process passes to block 244 which depicts the discardingof the element. Next, block 246 illustrates the removal of the requestfrom the scan queue in a manner consistent with the manner of theremoval of an element from a doubly linked list. Thereafter, block 248depicts using the real-time pointers in the scan queue element, to findthe next most urgent soft real-time request. The most urgent softreal-time buffer is updated. Next, block 250 illustrates informing CPU17 of the missed request. The process then passes back to block 202.

Referring again to block 242, if a determination is made that thedeadline has not passed, the process passes to block 252 whichillustrates using the pointer included in the most urgent soft real-timebuffer to go to that element. Next, block 254 depicts the removal of theelement from the scan queue in a manner consistent with the removal ofan element from a doubly linked list. Thereafter, block 256 illustratesthe updating of the scan pointer to point to this element. Block 258,then, depicts using the real-time pointers in this scan queue element tofind the next most urgent soft real-time request. The most urgent softreal-time buffer is updated. The process then passes back to block 219.

The following is a simplified example of the operation of the scanqueue. In this example, the scan queue includes ten logical memorylocations for storing scan queue elements. The disk has 1000 tracks.Currently, there are eight outstanding disk requests. Of these requests,three are hard real-time requests and three are soft real-time requests.The hard real-time requests are for tracks 345, 346, and 700. Track 345is the most urgent. Track 700 is the least urgent. The soft real-timerequests are for tracks 100, 101, and 102. Track 100 is the most urgent.Track 102 is the least urgent.

FIG. 7 depicts a scan queue having scan queue elements, a most urgentsoft real-time buffer, a most urgent hard real-time buffer, a currenttime clock, and current track scan pointer in accordance with the methodand system of the present invention. The current time is 10:31. The mosturgent hard real-time request must be serviced at or before 10:52. Themost urgent soft real-time request must be serviced at or before 10:43.The current scan track pointer is pointing to the logical memorylocation 5. The current track pointer indicates that the scan is to bein the ascending direction.

Assuming no further requests are received and that the next request canbe serviced before any deadlines are reached, the following occurs. Thecurrent track pointer points to the element stored at location 5. Thisis the request for track 101. When the disk is ready, this request isremoved from the scan queue and sent to the disk. The scan queue elementis removed using the standard methodology for removing an element from adoubly linked list.

FIG. 8 illustrates scan queue elements, a most urgent soft real-timebuffer, a most urgent hard real-time buffer, a current time clock, andcurrent track scan pointer of FIG. 7 after the next sequential request52 d has been removed in accordance with the method and system of thepresent invention. The current time is now shown to be 10:39. In thescan queue, the element at location 2 will be the next element removed.The scan queue ascending pointer of the element at location 3 is set tothe value of the scan queue ascending pointer of the removed element.Therefore, the scan queue ascending pointer 80 for element 3 is now setto 2. Similarly, the scan queue descending pointer of the element atlocation 2 is set to the value of the scan queue descending pointer ofthe element removed. Therefore, the scan queue descending pointer 82 forthe element at location 2 is now set to 3.

Since the element of the scan queue is a soft real-time request, thechain of soft real-time requests is also updated. By coincidence theelements of the scan queue that were effected are the same elements.However, this will typically not be the case. The real-time ascendingpointer of the element at location 3 is set to the value of thereal-time ascending pointer of the element removed. Similarly, thereal-time descending pointer of the element at location 2 is set to thevalue of the real-time descending pointer of the element removed. Thecurrent time has been changed to indicate the elapsed time.

Elements will be removed in track order: 101, 102, 345, 346, and 600.When it is time to remove the request for track 700 from the scan queue,the element at location 10 will have a descending pointer of 3 and anascending pointer of NULL. An ascending pointer of NULL is an indicationthat the highest track number of the elements currently on the scanqueue has been reached. At this point, the direction flag in the currenttrack pointer will be set to descending and the next request removedfrom the scan queue will be selected using the scan queue descendingpointer of the element at location 10. At this time the last request onthe scan queue will be removed in the following order: 700, 100, 50.

When the scan queue element at location 4 is removed, both its scanqueue ascending and descending pointers would have been set to NULL.This is assuming that no further elements have been added to the scanqueue. This is an indication that this is the last element in the scanqueue. When this element is removed, the scan queue empty indicator inthe status register is set to indicate that the scan queue is empty.

FIG. 9 depicts the scan queue having scan queue elements, the mosturgent soft real-time buffer, the most urgent hard real-time buffer, thecurrent time clock, and the current track scan pointer of FIG. 8 aftertwo more elements 52 a, 52 b have been removed and a non-real-timeelement 52 c has been added in accordance with the method and system ofthe present invention. The current time is now 10:43 which is the timethe most urgent soft real-time request is to be serviced. From the statedepicted in FIG. 8 to this current state, no deadline had elapsed. Thenext two sequential requests were serviced. These were the elements atlocation 2 and then at location 8. The element at location 8 was themost urgent hard real-time request since it has been service, before itsdeadline, the most urgent hard real-time request pointer has beenupdated. Using the real-time ascending pointer of the element atlocation 8, the element at location 6 is selected as the current mosturgent hard real-time request. Therefore, the hard real-time pointer isupdated with this location and deadline. The pointers on the element atlocation 6 have also been updated in a manner consistent with themanagement of a double linked list. The current time is now 10:43 whichis the deadline for the current most urgent soft real-time request. Thecurrent track pointer is set to point to the element at location 3 whichis the current most urgent soft real-time request. This will now be thenext element removed and the scan will continue sequentially from thispoint. The track pointer went from higher track numbers to lower tracknumbers in order to service the element at location 3. Since thedirection of the scan changed, the track pointer is updated fromascending to descending. A non-real-time request to track 500 has beenadded at location 9.

While an illustrative embodiment has been particularly shown anddescribed, it will be understood by those skilled in the art thatvarious changes in form and detail may be made therein without departingfrom the spirit and scope of the illustrative embodiment.

What is claimed is:
 1. A method in a data processing system fordynamically scheduling a plurality of requests to access a disk, each ofsaid plurality of requests being associated with a location on said diskwhich each of said plurality of requests attempts to access, said methodcomprising the steps of: establishing a scan queue for storing aplurality of requests; processing said plurality of requests in asequential order, said sequential order being determined utilizing saidlocation on said disk being accessed by each of said plurality ofrequests; upon one of said plurality of stored requests being urgent,processing said urgent request, said urgent request being associatedwith a first location on said disk; and continuing processing saidplurality of requests in a second sequential order, said secondsequential order being determined utilizing said first location, whereina next of said plurality of requests to be processed is one of saidplurality of requests which is associated with a physically closestlocation on said disk.
 2. The method according to claim 1, furthercomprising the step of determining a next of said plurality of requestsin said sequential order to be processed, said next of said plurality ofrequests being one of said plurality of requests having an associatedlocation on said disk physically closest to a last processed one of saidplurality of requests.
 3. The method according to claim 2, wherein saidstep of processing said plurality of requests further comprises the stepof processing said plurality of requests utilizing a disk arm travelingin either an ascending or descending direction.
 4. The method accordingto claim 3, further comprising the step of prior to determining saidnext of said plurality of requests in said sequential order, determininga disk arm direction.
 5. The method according to claim 4, wherein saidstep of determining a next of said plurality of requests in saidsequential order to be processed further comprises the step ofdetermining a next of said plurality of requests in said sequentialorder to be processed, said next of said plurality of requests being oneof said plurality of requests having an associated location on said diskphysically closest to a last processed one of said plurality of requestsin said determined disk arm direction.
 6. The method according to claim5, wherein said step of processing a plurality of requests furthercomprises the step of processing a plurality of requests including afirst plurality of requests and a second plurality of requests, saidfirst plurality of requests including only real-time requests and saidsecond plurality of requests including only non-real-time requests. 7.The method according to claim 6, further comprising the step ofprocessing said first plurality of requests, each of said firstplurality of requests having an associated deadline on or before whicheach of said first plurality of requests should be processed.
 8. Themethod according to claim 7, further comprising the step of processingsaid second plurality of requests, each of said second plurality ofrequests having an associated deadline on or before which each of saidsecond plurality of requests should be processed.
 9. The methodaccording to claim 8, wherein said step of one of said plurality ofstored requests being urgent further comprises the step of one of saidplurality of stored requests being at or past its deadline.
 10. Themethod according to claim 9, wherein said step of processing said firstplurality of requests further comprises the step of processing hardreal-time requests and soft real-time requests, wherein each of saidhard real-time requests must be processed on or before its associateddeadline to avoid catastrophic results, and where each of said softreal-time requests do not need to be processed on or before itsassociated deadline to avoid catastrophic results.
 11. The methodaccording to claim 10, further comprising the steps of: determining ifany of said hard real-time requests are at or past the deadlineassociated with each of said hard real-time requests; and in response toa determination that any of said hard real-time requests are at or pastthe deadline associated with each of said hard real-time requests,processing each of said hard real-time requests which are at or past thedeadline associated with each of said hard real-time requests.
 12. Themethod according to claim 11, further comprising the steps of:determining if any of said soft real-time requests are at the deadlineassociated with each of said soft real-time requests; and in response toa determination that any of said soft real-time requests are at thedeadline associated with each of said soft real-time requests,processing each of said soft real-time requests which are at thedeadline associated with each of said soft real-time requests.
 13. Themethod according to claim 12, further comprising the steps of:determining if any of said soft real-time requests are past the deadlineassociated with each of said soft real-time requests; and in response toa determination that any of said soft real-time requests are past thedeadline associated with each of said soft real-time requests,discarding each of said soft real-time requests which are past thedeadline associated with each of said soft real-time requests.
 14. Themethod according to claim 13, further comprising the step of for each ofsaid plurality of requests, maintaining a first pointer to a next ofsaid plurality of requests in said sequential order and maintaining asecond pointer to a previous of said plurality of requests in saidsequential order.
 15. The method according to claim 14, furthercomprising the step of for each of said hard real-time requests,maintaining a first pointer to a next most urgent of said hard real-timerequests and maintaining a second pointer to a next less urgent of saidhard real-time requests.
 16. The method according to claim 15, furthercomprising the step of for each of said soft real-time requests,maintaining a first pointer to a next most urgent of said soft real-timerequests and maintaining a second pointer to a next less urgent of saidsoft real-time requests.
 17. The method according to claim 16, furthercomprising the step of establishing a hard real-time buffer including apointer to one of said hard real-time requests which is the most urgentof said hard real-time requests and said buffer including a deadlineassociated with said one of said hard real-time requests which is themost urgent.
 18. The method according to claim 17, further comprisingthe step of establishing a soft real-time buffer including a pointer toone of said soft real-time requests which is the most urgent of saidsoft real-time requests and said buffer including a deadline associatedwith said one of said hard real-time requests which is the most urgent.19. The method according to claim 18, further comprising the step ofutilizing said first and second pointers to said hard real-time requeststo maintain said hard real-time buffer.
 20. The method according toclaim 19, further comprising the step of utilizing said first and secondpointers to said soft real-time requests to maintain said soft real-timebuffer.
 21. A data processing system for dynamically scheduling aplurality of requests to access a disk, each of said plurality ofrequests being associated with a location on said disk which each ofsaid plurality of requests attempts to access, comprising: means forestablishing a scan queue for storing a plurality of requests; means forprocessing said plurality of requests in a sequential order, saidsequential order being determined utilizing said location on said diskbeing accessed by each of said plurality of requests; means for upon oneof said plurality of stored requests being urgent, processing saidurgent request, said urgent request being associated with a firstlocation on said disk; and means for continuing processing saidplurality of requests in a second sequential order, said secondsequential order being determined utilizing said first location, whereina next of said plurality of requests to be processed is one of saidplurality of requests which is associated with a physically closestlocation on said disk.
 22. The system according to claim 21, furthercomprising means for determining a next of said plurality of requests insaid sequential order to be processed, said next of said plurality ofrequests being one of said plurality of requests having an associatedlocation on said disk physically closest to a last processed one of saidplurality of requests.
 23. The system according to claim 22, whereinsaid means for processing said plurality of requests further comprisesmeans for processing said plurality of requests utilizing a disk armtraveling in either an ascending or descending direction.
 24. The systemaccording to claim 23, further comprising means for prior to determiningsaid next of said plurality of requests in said sequential order,determining a disk arm direction.
 25. The system according to claim 24,wherein said means for determining a next of said plurality of requestsin said sequential order to be processed further comprises means fordetermining a next of said plurality of requests in said sequentialorder to be processed, said next of said plurality of requests being oneof said plurality of requests having an associated location on said diskphysically closest to a last processed one of said plurality of requestsin said determined disk arm direction.
 26. The system according to claim25, wherein said means for processing a plurality of requests furthercomprises means for processing a plurality of requests including a firstplurality of requests and a second plurality of requests, said firstplurality of requests including only real-time requests and said secondplurality of requests including only non-real-time requests.
 27. Thesystem according to claim 26, further comprising means for processingsaid first plurality of requests, each of said first plurality ofrequests having an associated deadline on or before which each of saidfirst plurality of requests should be processed.
 28. The systemaccording to claim 27, further comprising means for processing saidsecond plurality of requests, each of said second plurality of requestshaving an associated deadline on or before which each of said secondplurality of requests should be processed.
 29. The system according toclaim 28, wherein said means for one of said plurality of storedrequests being urgent further comprises means for one of said pluralityof stored requests being at or past its deadline.
 30. The systemaccording to claim 29, wherein said means for processing said firstplurality of requests further comprises means for processing hardreal-time requests and soft real-time requests, wherein each of saidhard real-time requests must be processed on or before its associateddeadline to avoid catastrophic results, and where each of said softreal-time requests do not need to be processed on or before itsassociated deadline to avoid catastrophic results.
 31. The systemaccording to claim 30, further comprising: means for determining if anyof said hard real-time requests are at or past the deadline associatedwith each of said hard real-time requests; and means responsive to adetermination that any of said hard real-time requests are at or pastthe deadline associated with each of said hard real-time requests, forprocessing each of said hard real-time requests which are at or past thedeadline associated with each of said hard real-time requests.
 32. Thesystem according to claim 31, further comprising: means for determiningif any of said soft real-time requests are at the deadline associatedwith each of said soft real-time requests; and means responsive to adetermination that any of said soft real-time requests are at thedeadline associated with each of said soft real-time requests, forprocessing each of said soft real-time requests which are at thedeadline associated with each of said soft real-time requests.
 33. Thesystem according to claim 32, further comprising: means for determiningif any of said soft real-time requests are past the deadline associatedwith each of said soft real-time requests; and means responsive to adetermination that any of said soft real-time requests are past thedeadline associated with each of said soft real-time requests, fordiscarding each of said soft real-time requests which are past thedeadline associated with each of said soft real-time requests.
 34. Thesystem according to claim 33, further comprising means for each of saidplurality of requests, for maintaining a first pointer to a next of saidplurality of requests in said sequential order and maintaining a secondpointer to a previous of said plurality of requests in said sequentialorder.
 35. The system according to claim 34, further comprising meansfor each of said hard real-time requests, for maintaining a firstpointer to a next most urgent of said hard real-time requests andmaintaining a second pointer to a next less urgent of said hardreal-time requests.
 36. The system according to claim 35, furthercomprising means for each of said soft real-time requests, formaintaining a first pointer to a next most urgent of said soft real-timerequests and maintaining a second pointer to a next less urgent of saidsoft real-time requests.
 37. The system according to claim 36, furthercomprising means for establishing a hard real-time buffer including apointer to one of said hard real-time requests which is the most urgentof said hard real-time requests and said buffer including a deadlineassociated with said one of said hard real-time requests which is themost urgent.
 38. The system according to claim 37, further comprisingmeans for establishing a soft real-time buffer including a pointer toone of said soft real-time requests which is the most urgent of saidsoft real-time requests and said buffer including a deadline associatedwith said one of said hard real-time requests which is the most urgent.39. The system according to claim 38, further comprising means forutilizing said first and second pointers to said hard real-time requeststo maintain said hard real-time buffer.
 40. The system according toclaim 39, further comprising means for utilizing said first and secondpointers to said soft real-time requests to maintain said soft real-timebuffer.